Wireless standards (Third Generation Partnership Program [3GPP] and 3GPP2 Voice Call Continuity [VCC]) are exploring mechanisms to allow VCC users to move between Circuit-Switched (CS) access (via cellular systems) and other wireless access (e.g., WiFi/Wireless LAN access into an IMS infrastructure).
It is important that the corresponding “domain transfer” mechanism, applied when an existing call is in progress in one domain, should allow the transfer of the existing bearer path to the alternate domain. The domain transfer mechanism should also support the transfer of a signaling path in the new domain. In addition, the user should ideally experience seamless mobility during and after the domain transfer.
To address service mobility, the industry has pursued two basic approaches—a distributed service execution model and an (IMS-based) centralized service execution model. FIG. 1 depicts the basic architecture of these two service models.
In the CS cellular model 100, voice services are typically offered via the Mobile Switching Center (MSC) 102. Such features can be MSC-based features 104, whereby the service logic resides in the MSC, and the MSC retrieves user profile information 106 from the Home Location Register (HLR) 108 to determine whether a selected feature is subscribed for and is active for a particular user. Alternatively, Intelligent Network (IN) based services 110 can be invoked, using triggers that are armed in the MSC—this mechanism causes the MSC to request instructions from a Service Control Point (SCP) 112, which executes IN service logic 110 that defines the particular service behavior.
In the IMS model 120, similar functionality is provided via a different mechanism. With IMS, the service logic 122 resides in an Application Server 124. The Home Subscriber Server (HSS) 126 stores user-related profile information 128, including initial Filter Criteria (iFC) that are used to trigger special service processing. This iFC mechanism is used to arm triggers 130 at a (Serving) Call Session Control Function (CSCF) 132. When a particular iFC condition is satisfied, the CSCF will communicate with a corresponding Application Server (as designated by the iFC), which will invoke the desired service behavior.
In general, the distributed service execution model attempts to offer services via the network where the user is currently attached. Thus, the user might access MSC-based or IN-based services when accessing the CS domain—but might access IMS-based services when accessing the IMS domain.
In contrast, the (IMS-based) centralized service execution model attempts to offer IMS-based services to the user, independent of the network where the user is currently attached (i.e., even when the user is accessing the CS domain). This model promotes consistent execution of IMS-based services, independent of the user's current access. This model makes more limited use of the CS service infrastructure (as required to enable IMS service execution).
The centralized service execution model offers a number of advantages over the distributed service execution model. For example, it provides a mechanism to allow the user's features to operate consistently, independent of the user's current access. The centralized service execution model also allows the user's features to be created in a common (IMS-based) manner—thereby avoiding the need to create and deploy multiple versions of the same services (for cellular and IMS domains). The model focuses the feature-interaction problem on a single (IMS) domain, eliminating the need to address interactions between services that might otherwise execute in different domains (e.g., as MSC-based features, IN-based features, or IMS-based features). The centralized service execution model is more forward-looking, consistent with the intended direction of some operators who desire to move toward an IMS-based network infrastructure. The model provides a framework for addressing some difficulties that might otherwise persist with the distributed service execution model. For example, if a user invokes an MSC-based multi-leg call feature, and then moves to the IMS domain, it may be difficult to transfer the current CS connection and call-state information to the IMS domain.
This problem is illustrated in FIG. 2. In FIG. 2, if a user handset 200 invokes an MSC-based multi-leg call feature 202, and subsequently wishes to transfer that connection and call-state information to the IMS domain, this might require the multiple bearer connections to be correlated and established in the IMS domain, in order to re-construct the current call state in the IMS domain. This can require complex processing—and would be further complicated if one of the existing CS call legs 204,206 happened to be on hold at the time of the domain transfer.
With the centralized service execution model, the MSC 300 would instead maintain a single bearer channel to the IMS domain (e.g., relying on a Media Resource Function (MRF) 302 within the IMS domain to provide any bridging/media-manipulation functionality). This is illustrated in FIG. 3.
FIG. 3 illustrates the need for a mechanism to exchange feature control 304 signaling between the user device 306 and an IMS-based Application Server 308. This mechanism should support bi-directional operation and should be enabled during an active CS call, allowing the network to send notifications to the user (e.g., notification of incoming call, as used in conjunction with call waiting) and allowing the user to send feature control information to the Application Server (e.g., “hold”, “join”, “request for pre-paid balance”, etc.)
Whereas existing mechanisms support the ability to exchange feature control messages when the user is served by the IMS domain (i.e., based on use of the Session Initiation Protocol (SIP)), there is a need for a mechanism that can be used to support such feature control signaling when the user is served by the CS domain as illustrated in FIG. 3.
For GSM networks, the use of Unstructured Supplementary Services Data (USSD) capability has been defined for this purpose—allowing a GSM handset to communicate with a network-based service platform. It is noted that this solution is not yet fully defined. Message formats for service requests need to be identified. Some options include the use of SIP templates or feature codes.
For CDMA network deployments, no USSD-like mechanism is currently available. However, the industry is currently exploring at least two options for this: (i) support for simultaneous packet and circuit service—where the packet capability might be used to enable communications between the user device and a network-based service platform during an active CS call; and, (ii) support for a modified Short Message Service (SMS) capability—allowing the user device to signal via the CS access network, which would then relay such messaging to a network-based service platform.
Currently, the USSD solution is only defined for GSM networks. Thus, there remains a need for a solution specifically targeted at CDMA networks, where USSD is not available. Other potential solutions for CDMA networks would require network modifications—making them more costly and potentially delaying the deployment of this capability.